<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Open Cloud Computing Interface - Use cases and requirements for a Cloud API</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.75.2"/></head><body><div class="article" title="Open Cloud Computing Interface - Use cases and requirements for a Cloud API"><div class="titlepage"><div><div><h1 class="title"><a id="id36063441"/>Open Cloud Computing Interface - Use cases and requirements for a
    Cloud API</h1></div><div><div class="author"><h3 class="author"><span class="firstname">Thijs</span> <span class="surname">Metsch</span></h3><div class="affiliation"><span class="orgname">Sun Microsystems<br/></span></div></div></div></div><hr/></div><h5><a id="id36063470"/>Status of This Document</h5><p>This document provides information to the Cloud and Grid community.
  Distribution is unlimited.</p><h5><a id="id36063479"/>Copyright Notice</h5><p>Copyright (c) Open Grid Forum (2009). All Rights Reserved.</p><h5><a id="id36063488"/>Abstract</h5><p>This document is an informal description of Use Cases and requirements
  for the OOCI Cloud API. Created by the Open Cloud Computing Interface
  working group. This document records the needs of IaaS Cloud computing
  managers and administrators in the form of Use Cases. The Use Cases serve as
  the primary guide for the development of API requirements. The document is
  the first deliverable to demonstrate and validate the features of the Open
  Cloud Computing Interface.</p><div class="section" title="Introduction"><div class="titlepage"><div><div><h2 class="title"><a id="id36063500"/>Introduction</h2></div></div></div><p>This document includes all the Use Cases and requirements which were
    gathered in the working group.</p><p>This document is organized in to three sections: Use Cases,
    Requirements and a comparison matrix of current Cloud APIs. In this
    document, Use Cases are defined by name and a set of functional and
    non-functional requirements. All requirements are catagorized and
    formatted in tables. Each requirement is (whenever possible) mapped to a
    Use Case. Priorities have been assigned to all requirements. The Cloud API
    comparison matrix itemizes generalized and detail features of each API and
    indicates which API supports each feature.</p></div><div class="section" title="OCCI Use Cases"><div class="titlepage"><div><div><h2 class="title"><a id="id36063518"/>OCCI Use Cases</h2></div></div></div><p>The following section describes the Use Cases which were gathered
  during the requirements analyses for the OCCI working group. They are used
  to set up the requirements and later on to verify the OCCI
  specification.</p><div class="section" title="SLA-aware cloud infrastructure using SLA@SOI"><div class="titlepage"><div><div><h3 class="title"><a id="id36063428"/>SLA-aware cloud infrastructure using SLA@SOI</h3></div></div></div><p>There is a need for a standard interface for dynamic infrastructure
    provisioning. While doing so it must be guaranteed and verified that the
    infrastructure provisioning uses 'machine-readable' SLAs. <span class="citerefentry"><span class="refentrytitle">(SLA_SOI)</span></span></p><h4><a id="id36065172"/>Functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>VM Description: request format important - In this area is where
        there is least coherency amongst providers.</p></li><li class="listitem"><p>VM Description: a means to add non-functional constraints on
        functional attributes.</p></li><li class="listitem"><p>VM Management: all parameters in the request should be
        "monitor-able" and verifiable. Full control of resources (VMs)
        allocated required; at a minimum: start, stop, suspend, resume.</p></li><li class="listitem"><p>VM Monitoring: Monitoring non-functional constraints declared in
        provisioning request</p></li><li class="listitem"><p>Network Management: resources assignable by network tag -
        defaults of public and private further sub-categorisation could be
        allowed e.g. tag of web could be assigned to the public network
        group.</p></li><li class="listitem"><p>Storage Management: simple mount points, reuse storage SaaS
        offerings</p></li></ul></div><h4><a id="id36065226"/>Non-functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Security: Transport and user level (ACLs? oAuth?)
        security</p></li><li class="listitem"><p>Quality of Service: Can be many - Part of service offering from
        the infrastructure provider e.g. Security, QoS, geo-location,
        isolation levels - NFPs are the basic building blocks of
        differentiating IaaS providers.</p></li><li class="listitem"><p>Scheduling Information: When a particular resource is to be run.
        Also in which order should a collection of resources be ran in the
        case that one resource is dependent on another.</p></li></ul></div></div><div class="section" title="Service Manager to control the Life cycle of Services"><div class="titlepage"><div><div><h3 class="title"><a id="id36065258"/>Service Manager to control the Life cycle of Services</h3></div></div></div><p>This Use Case is based in the 'Service Manager' (SM) layer of the
    RESERVOIR project architecture. 'Service Providers' (SP) willing to deploy
    their service on the Cloud use this layer to control the service life
    cycle. The SM operates over the Cloud infrastructure automatically as the
    service demands. In a way, the SM maps the service configuration and needs
    to calls to the Cloud infrastructure, so many of the requirements imposed
    by the SM are due to the flexibility that the SM aims to provide to SPs.
    (<span class="citerefentry"><span class="refentrytitle">RV</span></span>)</p><h4><a id="id36065280"/>Functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Network Management: There should be methods for the Allocation
        of private networks, where VMs can be attached to. A special network
        (e.g. 'Public Network') should be available. When some network
        interface is attached to it, the infrastructure must assign a public
        IP address.</p></li><li class="listitem"><p>Image Management: There should be methods to register, upload,
        update and download disk images.</p></li><li class="listitem"><p>VM Description: It should be possible to describe all the VM
        hardware components and their attributes, along with any restriction
        regarding the VM location:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Memory: Size</p></li><li class="listitem"><p>CPU: Architecture, amount of CPU's and speed.</p></li><li class="listitem"><p>Disk: Size, Interface (SCSI, IDE, SATA...), RAID (yes/no,
            and RAID level), Disk image to mount, Automatic backup (yes/no,
            backups frequency...).</p></li><li class="listitem"><p>Network: Interfaces, for each interface its bandwidth, and
            Network they are attached to.</p></li><li class="listitem"><p>Geographical restrictions: Location(s) where the VM
            can/cannot be deployed (for example for legal purposes).</p></li><li class="listitem"><p>Migration allowed (yes/no): If migration is supported by the
            infrastructure, this flag sets if it is allowed for the VM.</p></li></ul></div></li><li class="listitem"><p>VM Management: There should be methods to allow the SM to change
        the VM state (for example, from ACTIVE to SUSPENDED), if such
        transition is allowed by the infrastructure (i.e. is defined in the
        OCCI's State Machine). The description of a VM can be changed when the
        machine is running (ACTIVE, SUSPENDED...). But it will not be taken
        into account until the machine is stopped and started again, unless it
        is a change regarding geographical or migration restrictions. Each
        disk backup will have an id, as the images defined by the SM. Methods
        to download any backup should be provided. As each backup is, after
        all, a disk image, it should be possible to mount it on any VM. For
        example, it should be possible to stop a VM, change its configuration
        so its disk mounts this backup image, and restart the VM.</p></li><li class="listitem"><p>Monitoring: The status (We use the term 'status' when talking
        about monitoring, and try not to use the term 'state' to avoid
        confusion with the states of the OCCI State Machine.) representation
        of any element is given as a list of keys and their values. For
        example, the status of a memory component could be given by the amount
        of memory used and the cache memory. Then, the keys could be: 'used'
        and 'cache' with the values '142MB' and '430MB'. Both the request and
        the reply use the corresponding element identifier. Two types of
        monitoring should be supported:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Pull based: The SM can request the status of any element it
            has registered: VMs, networks... Also, the SM can request the
            status of components, for example, the status of certain disk of a
            certain VM.</p></li><li class="listitem"><p>Publish/subscribe based: The SM can subscribe to be notified
            about events on the VMs and/or Networks. Some of the events to be
            notified are:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Errors on some component of a VM.</p></li><li class="listitem"><p>Changes on the state of a VM (e.g. from ACTIVE to
                SUSPENDED).</p></li><li class="listitem"><p>Periodic notifications about some element state. The
                frequency of this notifications can be configured in the
                subscription message.</p></li></ul></div></li></ul></div></li><li class="listitem"><p>Error messages: If a VM could not be created, or a image could
        not be uploaded, etc... the platform should return an error message
        carrying a detailed description of the reason.</p></li><li class="listitem"><p>Identifications: Networks, VMs and images should have unique
        IDs, (UUIDs, URIs, or the like). It is to be determined whether
        components of VMs (disks, memory...) should have an unique ID too. IDs
        are assigned by the Cloud infrastructure when the corresponding
        element is created.</p></li></ul></div><h4><a id="id36065454"/>Non-functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Both for hardware configuration and monitoring values there
        should be a clear, standard way to set which magnitude the value
        represents. For example, when setting the memory size to '2', it must
        be clear that we refer to GBs and not to MBs. An option would be
        setting the value to '2GB', another would be allowing to set both the
        value and the magnitude: value '2' and magnitude 'GB'.</p></li><li class="listitem"><p>Protocols: The transport, message format, and state
        representation should use open and standard protocols, each one which
        strong software support (i.e. libraries and frameworks available for
        several programming languages).</p></li></ul></div></div><div class="section" title="Interoperability across Cloud Infrastructures using OpenNebula"><div class="titlepage"><div><div><h3 class="title"><a id="id36065480"/>Interoperability across Cloud Infrastructures using
    OpenNebula</h3></div></div></div><p>OpenNebula is a Virtual Infrastructure Engine, being enhanced in the
    RESERVOIR project, which allows the management of Virtual Machines on a
    pool of physical resources It offers three main functionalities: backend
    of a public cloud, manage a virtual infrastructure in the data-center or
    cluster (private cloud), achieve cloud interoperation (hybrid cloud), the
    latter being relevant in this Use Case.</p><p>The aim of this Use Case is to state the requirements that an API
    for cloud providers should take into account in order to expose an
    interface that will enable the management of groups of Virtual Machines
    across them. These requirements are gathered from the experience using
    OpenNebula to manage Virtual Machines from different cloud providers.
    Currently, there are two set of plugins for OpenNebula to access Amazon
    EC2 and ElasticHosts cloud providers that leverage the use of both cloud
    providers in a transparent fashion for the end user. (<span class="citerefentry"><span class="refentrytitle">ONE</span></span>)</p><h4><a id="id36065509"/>Functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>VM Description: Virtual Machines should be described
        consistently across cloud providers using a slim set of indispensable
        attributes, such as:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Memory: Amount of RAM needed by the Virtual Machine</p></li><li class="listitem"><p>CPU: Number of CPUs needed by the Virtual Machine (this
            needs to be normalized)</p></li><li class="listitem"><p>Disk: Disks that will conform the basic filesystem and
            possibly others for the Virtual Machine</p></li><li class="listitem"><p>Network: How many network interface this Virtual Machine
            should have, and where should be attached</p></li></ul></div></li><li class="listitem"><p>VM Management: API should offer functionality to enforce
        operations upon Virtual Machines, such as:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>DEPLOY: Launches the Virtual Machine</p></li><li class="listitem"><p>SHUTDOWN: Shutdown the Virtual Machine</p></li><li class="listitem"><p>CANCEL: Cancels the Virtual Machine in case of failure, or
            destroys it if it is running</p></li><li class="listitem"><p>CHECKPOINT: Creates a snapshot of the Virtual Machine</p></li><li class="listitem"><p>SAVE: Creates a snapshot of the Virtual Machine AND suspends
            it</p></li><li class="listitem"><p>RESTORE: Resumes a Virtual Machine from a previous
            snapshot</p></li><li class="listitem"><p>POLL: Retrieves information about Virtual Machine state and
            consumption attributes (percentage of Memory, CPU used, bytes
            transferred, and so on)</p></li></ul></div></li><li class="listitem"><p>Additionally, Virtual Machines should be in one of the following
        states:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>PENDING: VM is waiting for a physical resource slot.</p></li><li class="listitem"><p>BOOTING: VM is being booted</p></li><li class="listitem"><p>RUNNING: VM is active, it should be able to start offering a
            service</p></li><li class="listitem"><p>SUSPENDED: VM is suspended, waiting for a resume.</p></li><li class="listitem"><p>SHUTDOWN: VM is being shutdown.</p></li><li class="listitem"><p>CANCEL: VM has been canceled by the user or by a
            scheduler.</p></li><li class="listitem"><p>FAILED: VM crashed or hasn't started properly.</p></li></ul></div></li><li class="listitem"><p>Network Management: API should expose functionality to</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Create Private Virtual Networks</p></li><li class="listitem"><p>Attach Public IP to Virtual Machine</p></li></ul></div></li><li class="listitem"><p>Image Management: The ability to upload disk images is
        fundamental to virtual machine management to avoid the need to
        reinstall software for each cloud provider. The upload process should
        return an identifier to be used in the Virtual Machine
        Description.</p></li></ul></div><h4><a id="id36065718"/>Non-functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Security: Security should be handled using X509 certificates for
        authentication. Also, authorization can be based on said certificates
        and ACL lists.</p></li><li class="listitem"><p>Quality of Service: When used in conjunction with Haizea,
        OpenNebula provides advanced reservation functionality. Cloud
        providers API should provide similar capabilities to ensure proper
        QoS.</p></li></ul></div></div><div class="section" title="AJAX web front-end directly calling API"><div class="titlepage"><div><div><h3 class="title"><a id="id36065742"/>AJAX web front-end directly calling API</h3></div></div></div><p>This Use Case describes the ability to create web front-ends for
    Clouds. A cloud provider implements their customer web front-end as an
    entirely client-side AJAX application calling the OCCI API
    directly.</p><h4><a id="id36065754"/>Functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Completeness: API must be contain complete set of calls to
        completely specify and control cloud (but this is likely only ~15-20
        verbs on ~3-4 nouns!)</p></li><li class="listitem"><p>Responsiveness: Calls must return swiftly. In particular, we
        should provide a simple and quick call to poll the _list_ of servers,
        drives, etc. that exist without listing all of their properties, since
        this is computationally much cheaper for the cloud to return, and will
        need to be regularly polled to catch any servers, etc. that are
        created outside of the interface.</p></li></ul></div><h4><a id="id36065780"/>Non-functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Syntax: A simple JSON syntax for the API will make the AJAX
        interface much simpler to implement</p></li></ul></div></div><div class="section" title="Single technical integration to support multiple service providers"><div class="titlepage"><div><div><h3 class="title"><a id="id36065795"/>Single technical integration to support multiple service
    providers</h3></div></div></div><p>Today, each cloud provider (ElasticHosts, GoGrid, Amazon, etc.)
    integrates independently with every other player in the cloud ecosystem
    (CohesiveFT, RightScale, etc), producing O(n^2) separate technical
    integrations. In the future, if all cloud providers and cloud ecosystem
    partners use a single standard API, then we have O(n) technical
    integrations, and all potential partnerships can immediately
    interoperate.</p><h4><a id="id36065809"/>Non-functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Uptake: Standardized IaaS API needs strong uptake in by both
        cloud providers and cloud ecosystem.</p></li></ul></div></div><div class="section" title="Wrapping EC2 in OCCI"><div class="titlepage"><div><div><h3 class="title"><a id="id36065824"/>Wrapping EC2 in OCCI</h3></div></div></div><p>At the time of this writing, Amazon EC2 is popular cloud API for
    IaaS. Cloud providers implementing EC2 as well as other proprietary and
    open cloud APIs may not implement OCCI. To help ensure that the OCCI API
    would be capable of interfacing to EC2 though gateways, minimizing the
    impact to provider operations. </p><h4><a id="id36065836"/>Functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Semantics: Must include the ability to fully describe core EC2
        objects and operations</p></li></ul></div><h4><a id="id36065851"/>Non-functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>A gateway to support the integration of OCCI and EC2</p></li></ul></div></div><div class="section" title="Automated Business Continuity and Disaster Recovery"><div class="titlepage"><div><div><h3 class="title"><a id="id36065865"/>Automated Business Continuity and Disaster Recovery</h3></div></div></div><p>Maintain a up-to-date remote shadows of physical and/or virtual
    machines, such that in the event of a disaster it is possible to start and
    switch to the remote machines.</p><h4><a id="id36065877"/>Functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>VM Description: Metadata mapping to legacy systems</p></li><li class="listitem"><p>VM Management: Automated management in the event of a disaster
        (e.g. startup, IP changes).</p></li><li class="listitem"><p>Network Management: Runtime alteration of IPs</p></li><li class="listitem"><p>Image Management: Advanced, rsync style updates to synchronise
        machines with physical equivalents (e.g. rsync block devices to remote
        raw disk files).</p></li></ul></div><h4><a id="id36065915"/>Non-functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Quality of Service: Reservation of capacity sufficient for fail
        over</p></li></ul></div></div><div class="section" title="Simple scripting of cloud from Unix shell"><div class="titlepage"><div><div><h3 class="title"><a id="id36065929"/>Simple scripting of cloud from Unix shell</h3></div></div></div><p>An end user wishes to script a simple task (such as starting a
    server at midnight every night and shutting it down an hour later,
    automating fail over, reporting, etc.). They are using a typical
    Unix/Linux setup, so would like to write a simple cron job which carries
    this out.</p><h4><a id="id36065942"/>Non-functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Syntax: This should be as simple as possible to place minimal
        barriers to entry on the user. The user should not need any
        development tools or libraries. They should be able to write 1-2 lines
        of shell script, posting a simple &lt;5 lines of command data using
        curl, wget, etc.</p></li></ul></div></div><div class="section" title="Typical web hosting cluster"><div class="titlepage"><div><div><h3 class="title"><a id="id36065958"/>Typical web hosting cluster</h3></div></div></div><p>An end-user runs a typical web hosting cluster on a cloud, with: n
    database servers, m front-end web server (bursting to x under load) and a
    load balancer (either a specialized virtual machine or provided by the
    cloud like GoGrid).</p><h4><a id="id36065970"/>Functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Completeness: The API should be able to fully express this
        cluster, which will require at least: (n+m+x) virtual machines,
        storage for each virtual machine, two networks (a private one
        connecting the machines, and the public Internet also connected to the
        load balancer), a fixed static IP for the website on the public
        Internet, possible specification of the load balancer itself.</p></li></ul></div></div><div class="section" title="Manage cloud resources from a centralized dashboard"><div class="titlepage"><div><div><h3 class="title"><a id="id36065988"/>Manage cloud resources from a centralized dashboard</h3></div></div></div><p>An end user wishes to view and control all of his cloud-based
    resources in a lightweight (perhaps AJAX-based) console, perhaps the same
    web front-end referred to in this Use Case: AJAX web front-end directly
    calling API</p><h4><a id="id36066000"/>Functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Completeness: Every resource provided by the cloud is
        discoverable by the API, and every action that can be performed on all
        these resources is also available via the API, together with actuators
        to actually perform those actions, and all the attributes of the
        resources are available via the API.</p></li><li class="listitem"><p>Responsiveness: Calls must return swiftly. In particular, we
        should provide a simple and quick call to poll the _list_ of servers,
        drives, etc. that exist without listing all of their properties, since
        this is computationally much cheaper for the cloud to return, and will
        need to be regularly polled to catch any servers, etc. that are
        created outside of the interface. (text copied from AJAX web front-end
        directly calling API)</p></li><li class="listitem"><p>Categorizability: (there's gotta be a better word...) The client
        must be able to identify what type each resource is in order to
        display like-typed resources together and in order to provide separate
        UI views that might be specialized for certain resource types. For
        example, the client must be able to differentiate between a compute
        resource that does not represent an actual CPU (perhaps this is a
        compute template) and between a compute resource that actually
        represents a running CPU. The interface for actually-running CPUs
        might display the current IP address of the instance and allow you to
        SSH into the instance, while a different tab in the interface might
        display all the compute templates and allow you to instantiate
        instances from them.</p></li><li class="listitem"><p>Taggability: Every resource discoverable by the API must be able
        to be tagged by the user. This supports the oft-occurring situation
        where resources, though they are identified by the
        implementation-specific identifier, are easily identified using
        terminology defined by the user for his specific context. For example,
        one might tag resource "/compute/instanceABCDEFG" with the label
        "database server", and the resource "/storage/disk12345678" with the
        label "superSecretCorporateData".</p></li><li class="listitem"><p>Searchability: The ability to request lists of resources must
        allow an optional filter that can specify a category or tag upon which
        to filter the results. This allows one to further limit their view to,
        for example, resources tagged "productionEnvironment", or resources of
        the category "storage".</p></li></ul></div><h4><a id="id36066062"/>Non-functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Usability: This should be a user interface with context-menus
        and context-aware links that allow the user to easily see what actions
        can be performed for each resource.</p></li></ul></div></div><div class="section" title="Compute Cloud"><div class="titlepage"><div><div><h3 class="title"><a id="id36066078"/>Compute Cloud</h3></div></div></div><p>A cloud provider implements a RESTful API for provisioning,
    executing, and monitoring of tasks.</p><h4><a id="id36066088"/>Functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Secure: API must be secured to ensure that only authorized
        identities are permitted to use the API.</p></li><li class="listitem"><p>Resource: An endpoint must be created for external monitoring,
        status, and auditing of the task. This endpoint would be responsive to
        RESTful calls supporting AJAX and other clients.</p></li><li class="listitem"><p>Scripted: The target system needs to understand and process
        directives which would be provided with the task. These directives
        would include the ability to pull binaries or data onto the system,
        run executables, and status the system resources.</p></li></ul></div><h4><a id="id36066121"/>Non-functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Single Compute Method: The resultant service should be the same
        service that can be used for many other purposes. It could be used for
        monitoring of system health, system life-cycle management, system
        patching, and configuration changes. If this was the only service on
        the system initially, it could then be used to build up the other
        services in a plug-in manner.</p></li></ul></div></div><div class="section" title="Multiple Allocation"><div class="titlepage"><div><div><h3 class="title"><a id="id36066138"/>Multiple Allocation</h3></div></div></div><p>Allocate a whole cluster with one call.</p><h4><a id="id36066148"/>Functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>Definition of groups: There should be a way to define groups of
        computers. In the example of a cluster, there would be two groups: The
        Headnode and a couple of Workernodes.</p></li><li class="listitem"><p>Information: For configuration of the members of the defined
        groups, there should be way (maybe a URL) to find out about all groups
        and their basic configurations. In the example, the Headnode would
        want to know IPs or Hostnames of all Workernodes. The workernodes will
        need to know this, as well _and_ they need to know, that the headnode
        is in a different group.</p></li></ul></div></div><div class="section" title="Cloud Consumer Discovery of Cloud Provider's VM Input and Output Format Support"><div class="titlepage"><div><div><h3 class="title"><a id="id36066174"/>Cloud Consumer Discovery of Cloud Provider's VM Input and Output
    Format Support</h3></div></div></div><p>A cloud consumer would like to discover the VM input and output
    formats accepted and delivered by the cloud provider.</p><h4><a id="id36066185"/>Functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>The provider supplies an API which is availed over unsecured
        network connections.</p></li><li class="listitem"><p>The provider supplies an API which is availed over secured
        network connections.</p></li><li class="listitem"><p>The provider supplied API is availed for all consumer
        authentication and authorization levels.</p></li><li class="listitem"><p>The provider supplied API identifies the supported VM input
        formats API uniquely and commonly across all providers.</p></li><li class="listitem"><p>The provider supplied API identifies the supported VM output
        formats API uniquely and commonly across all providers.</p></li><li class="listitem"><p>The provider supplied API identifies the supported VM formats
        uniquely and commonly across all providers.</p></li><li class="listitem"><p>The provider API identifies mutliple supported VM input formats
        as a list uniquely and commonly across all providers</p></li><li class="listitem"><p>The provider API identifier is unique and and consistent across
        all API representations.</p></li><li class="listitem"><p>The provider API VM input and output format identifiers are
        unique and and consistent across all providers.</p></li><li class="listitem"><p>The reported VM input and output formats are not required to be
        symetrical and equal and in consistent order.</p></li></ul></div></div><div class="section" title="Cloud Consumer Discovery of Cloud Provider's Dataset Input and Output Format Support"><div class="titlepage"><div><div><h3 class="title"><a id="id36066270"/>Cloud Consumer Discovery of Cloud Provider's Dataset Input and
    Output Format Support</h3></div></div></div><p>A cloud consumer would like to discover the Dataset input and output
    formats accepted and delivered by the cloud
    provider.</p><h4><a id="id36066281"/>Functional Requirements</h4><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>The provider supplies an API which is availed over unsecured
          network connections.</p></li><li class="listitem"><p>The provider supplies an API which is availed over secured
          network connections.</p></li><li class="listitem"><p>The provider supplied API is availed for all consumer
          authentication and authorization levels.</p></li><li class="listitem"><p>The provider supplied API identifies the supported Dataset
          input formats API uniquely and commonly across all providers.</p></li><li class="listitem"><p>The provider supplied API identifies the supported Dataset
          output formats API uniquely and commonly across all
          providers.</p></li><li class="listitem"><p>The provider supplied API identifies the supported Dataset
          formats uniquely and commonly across all providers.</p></li><li class="listitem"><p>The provider API identifies multiple supported Dataset formats
          as a list uniquely and commonly across all providers</p></li><li class="listitem"><p>The provider API identifier is unique and and consistent
          across all API representations.</p></li><li class="listitem"><p>The provider API Dataset input and output format identifiers
          are unique and and consistent across all providers.</p></li><li class="listitem"><p>The reported Dataset input and output formats are not required
          to be symetrical and equal and in consistent order.</p></li></ul></div></div></div><div class="section" title="OCCI Requirements"><div class="titlepage"><div><div><h2 class="title"><a id="id36063538"/>OCCI Requirements</h2></div></div></div><div class="section" title="Functional Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="id36063983"/>Functional Requirements</h3></div></div></div><p>This section deals with the funtional requirements. The requirments
    have been split up in tables and prioritized.</p><div class="table"><a id="id36066911"/><p class="title"><b>Table 1. Functional requirements on VM description</b></p><div class="table-contents"><table summary="Functional requirements on VM description" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.1.1</td><td>Attributes to define memory, CPU, disk and network
            requirements should be available.</td><td>2.2, 2.3, 2.6</td><td>High</td></tr><tr><td>A.1.2.</td><td>Attributes to define placement constraints, such as
            geographical location must be supported</td><td>2.2</td><td>Medium</td></tr><tr><td>A.1.3.</td><td>A attributes should demonstrate if migration is supported
            by the infrastructure</td><td>2.2</td><td>Medium</td></tr><tr><td>A.1.4.</td><td>The API should be able to fully express a cluster (e.g. 5
            VMs, storage for each VM, two networks (a private one connecting
            the machines, and the public internet also connected to the load
            balancer), a fixed static IP for the website on the public
            internet)</td><td>2.9</td><td>High</td></tr><tr><td>A.1.5.</td><td>A means to add constraints (non-functional, functional) on
            attributes which are declared in a provisioning request</td><td>2.1</td><td>High</td></tr><tr><td>A.1.6.</td><td>Support the scheduling of resource execution. Allow
            provisioned resources to be execute sometime in the future from
            the original request</td><td>2.1</td><td>Medium</td></tr><tr><td>A.1.7.</td><td>Common operating systems should be supported</td><td>-</td><td>High</td></tr><tr><td>A.1.8.</td><td>Resources should be grouped according to provider
            policies</td><td>-</td><td>High</td></tr><tr><td>A.1.9.</td><td>Then requesting new resource(s) the request must be fully
            complete/describing</td><td>-</td><td>High</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067153"/><p class="title"><b>Table 2. Functional requirements on VM management</b></p><div class="table-contents"><table summary="Functional requirements on VM management" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.2.1.</td><td>Methods to start, stop, suspend and resume VMs must be
            available</td><td>2.1, 2.2, 2.3, 2.5, 2.11, 2.10</td><td>High</td></tr><tr><td>A.2.2.</td><td>Automated management in the event of a disaster should be
            supported</td><td>2.1, 2.7</td><td>Low</td></tr><tr><td>A.2.3.</td><td>Provide IDs for each backup disk and images</td><td>2.2</td><td>High</td></tr><tr><td>A.2.4.</td><td>Provide methods to donwload any backup</td><td>2.2</td><td>Medium</td></tr><tr><td>A.2.5.</td><td>API should offer functionality to enforce the following
            operations: deploy, shutdown, cancel, checkpoint, save, restore,
            poll (could be merged with monitoring)</td><td>2.3</td><td>High</td></tr><tr><td>A.2.6.</td><td>The state model should include: pending, booting, running,
            suspended, shutdown, cancel, failed</td><td>2.3</td><td>Medium</td></tr><tr><td>A.2.7.</td><td>Listing collections should be possible without listing all
            properties for each entry</td><td>2.4</td><td>Medium</td></tr><tr><td>A.2.8.</td><td>Allow resource representations to be updated and have those
            changes trigger events/changes upon VMs</td><td>-</td><td>Low</td></tr><tr><td>A.2.9.</td><td>Support the usage of terminal, web, desktop and automated
            management interfaces</td><td>2.10</td><td>Low</td></tr><tr><td>A.2.10.</td><td>Support the migration of resources from a physical resource
            to the cloud, from a cloud to another cloud and from a virtual
            resource to the cloud (This is a topic regarding
            Interoperability)</td><td>-</td><td>Medium</td></tr><tr><td>A.2.11.</td><td>Support a subset of all functions of today IaaS based
            Clouds (e.g. Amaton EC2)</td><td>2.6</td><td>Medium</td></tr><tr><td>A.2.12.</td><td>A common interface should be used which can be supported by
            many Cloud service providers (regarding Infrastructure and Data
            interfaces).</td><td>2.13, 2.14</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067441"/><p class="title"><b>Table 3. Functional requirements on Network management</b></p><div class="table-contents"><table summary="Functional requirements on Network management" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.3.1.</td><td>Support the creation of VPNs</td><td>2.3</td><td>Low</td></tr><tr><td>A.3.2.</td><td>Support multiple network connection (Public and
            Private)</td><td>2.1, 2.2, 2.3</td><td>High</td></tr><tr><td>A.3.3.</td><td>It must be possible to attach and change IPs at
            runtime</td><td>2.3, 2.7</td><td>Medium</td></tr><tr><td>A.3.4.</td><td>Support a tagging mechanism for a group of network
            connections</td><td>2.1, 2.2, 2.3</td><td>Low</td></tr><tr><td>A.3.5.</td><td>Support network setups which allow an 'Intercloud' setup
            (This relates to Integration)</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067600"/><p class="title"><b>Table 4. Functional requirements on Storage management</b></p><div class="table-contents"><table summary="Functional requirements on Storage management" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.4.1.</td><td>Allow the usage of URIs as mount points - allows reuse of
            Storage service offerings</td><td>2.1</td><td>High</td></tr><tr><td>A.4.2.</td><td>Allow the attachment of additional storage resources at
            runtime</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067706"/><p class="title"><b>Table 5. Functional requirements on Image management</b></p><div class="table-contents"><table summary="Functional requirements on Image management" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.5.1.</td><td>Methods which are capable to register, upload, update and
            download disk images must be available.</td><td>2.2</td><td>Medium</td></tr><tr><td>A.5.2.</td><td>Updates based on rsync commands to synchronize machines
            with physical equivalents should be supported</td><td>2.7</td><td>Medium</td></tr><tr><td>A.5.3.</td><td>When an upload completes successfully, an identifier should
            be returned</td><td>2.2</td><td>Low</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067830"/><p class="title"><b>Table 6. Identifications/References</b></p><div class="table-contents"><table summary="Identifications/References" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.6.1.</td><td>Unique IDs for VM images and their components must be
            available</td><td>2.2, 2.13, 2.14</td><td>High</td></tr><tr><td>A.6.2.</td><td>It must be possbile to tag resources and their
            components</td><td>2.10, 2.12</td><td>Medium</td></tr><tr><td>A.6.3.</td><td>It must be possible to search for resources based on e.g.
            tags.</td><td>2.10, 2.12</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36067954"/><p class="title"><b>Table 7. Monitoring</b></p><div class="table-contents"><table summary="Monitoring" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>A.7.1.</td><td>Support pull-based monitoring that request the status of
            the elements such as network , VM ...</td><td>2.1, 2.2, 2.3</td><td>Medium</td></tr><tr><td>A.7.2.</td><td>Support for a publish/subscribe pattern that request events
            which occur in the VM or networks (such as Errors on some
            component, changes in the VM state and other periodic
            notifications)</td><td>2.2</td><td>Medium</td></tr><tr><td>A.7.3.</td><td>Attributes that define simple quick call to poll the list
            of servers, drives, etc should monitorable</td><td>2.4</td><td>Low</td></tr><tr><td>A.7.4.</td><td>Attributes about resource consumption of the VM from the
            hypervisor (CPU, memory...) should be monitorable</td><td>2.1, 2.2</td><td>Medium</td></tr><tr><td>A.7.5.</td><td>Management reports should be generated from in some of the
            following formats XML, PDF</td><td>-</td><td>Low</td></tr></tbody></table></div></div><br class="table-break"/></div><div class="section" title="Non-functional Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="id36068115"/>Non-functional Requirements</h3></div></div></div><p>This section deals with all the non-funtional requirements.</p><div class="table"><a id="id36068126"/><p class="title"><b>Table 8. Security requirements</b></p><div class="table-contents"><table summary="Security requirements" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>B.1.1.</td><td>Support the usage of X509 Certificates</td><td>2.3, 2.13, 2.14</td><td>High</td></tr><tr><td>B.1.2.</td><td>Support the usage of ACLs</td><td>B.1, 2.1</td><td>High</td></tr><tr><td>B.1.3.</td><td>Attributes to define Security levels should be available in
            the descriptions</td><td>2.1</td><td>High</td></tr><tr><td>B.1.4.</td><td>Transport and user level security should be given</td><td>2.1, 2.13, 2.14</td><td>High</td></tr><tr><td>B.1.5.</td><td>Allow geographical region to be specified</td><td>B.4</td><td>High</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36068284"/><p class="title"><b>Table 9. Quality of Service</b></p><div class="table-contents"><table summary="Quality of Service" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>B.2.1.</td><td>Support capacities requirements for recovery / failover
            cases</td><td>2.7</td><td>Low</td></tr><tr><td>B.2.2.</td><td>Support of attributes in the VM description to define QoS
            level (this also includes the reponse times)</td><td>2.1</td><td>High</td></tr><tr><td>B.2.3.</td><td>Support of attributes in the VM describing the Isolation
            level</td><td>2.1</td><td>Medium</td></tr><tr><td>B.2.4.</td><td>Support of attributes for an advanced reservation
            functionality</td><td>2.3</td><td>Low</td></tr><tr><td>B.2.5.</td><td>Allow VM response times to be specified</td><td>B.4</td><td>High</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36068443"/><p class="title"><b>Table 10. Syntax</b></p><div class="table-contents"><table summary="Syntax" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>B.3.1.</td><td>No development tools or libraries should be needed by the
            end-user</td><td>2.8</td><td>Medium</td></tr><tr><td>B.3.2.</td><td>Support simple JSON syntax to suppot Ajax interface</td><td>2.4, 2.10</td><td>Medium</td></tr><tr><td>B.3.3.</td><td>Clear definition of units (MB, GB etc) should be used in
            the requests (Like those defined by IEC 60027-2 A.2)</td><td>A.2, 2.4</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/><div class="table"><a id="id36068567"/><p class="title"><b>Table 11. Backup/Disaster recovery</b></p><div class="table-contents"><table summary="Backup/Disaster recovery" border="1"><colgroup><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">ID</th><th style="text-align: center">Description</th><th style="text-align: center">Usecases</th><th style="text-align: center">Priority</th></tr></thead><tbody><tr><td>B.4.1.</td><td>Support a backup functionality of cloud resources</td><td>-</td><td>Low</td></tr><tr><td>B.4.2.</td><td>The interface should reconsider failover, disaster recovery
            and business continuity plans</td><td>-</td><td>Medium</td></tr></tbody></table></div></div><br class="table-break"/></div></div><div class="section" title="Cloud API feature Matrix"><div class="titlepage"><div><div><h2 class="title"><a id="id36063558"/>Cloud API feature Matrix</h2></div></div></div><p>Existing APIs for IaaS based Clouds already fulfill some of the Use
  cases and also address some requirements. The following list of APIs have
  been evaluated during the creation of the OCCI working group process.</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>OCCI - Open Cloud Computing Interface</p></li><li class="listitem"><p>EC2 - Amazon Elastic Compute Cloud</p></li><li class="listitem"><p>EH - ElasticHosts</p></li><li class="listitem"><p>FS - Flexiscale</p></li><li class="listitem"><p>GG - GoGrid</p></li><li class="listitem"><p>SC - Sun Cloud API</p></li><li class="listitem"><p>CS - Rackspace Cloud Servers</p></li><li class="listitem"><p>VM - WMware vSphere</p></li></ul></div><p>While this is not a complete or in depth evaultation of the APIs the
  following Matrix can used as a basic reference point for API
  comparism.</p><div class="table"><a id="id36064514"/><p class="title"><b>Table 12. Cloud API feature matrix</b></p><div class="table-contents"><table summary="Cloud API feature matrix" border="1"><colgroup><col/><col/><col/><col/><col/><col/><col/><col/><col/><col/></colgroup><thead><tr><th style="text-align: center">Feature</th><th style="text-align: center">Requirement</th><th style="text-align: center">OCCI</th><th style="text-align: center">EC2</th><th style="text-align: center">EH</th><th style="text-align: center">FS</th><th style="text-align: center">GG</th><th style="text-align: center">SC</th><th style="text-align: center">CS</th><th style="text-align: center">VM</th></tr></thead><tbody><tr><td>Authentication via HTTP</td><td>Client compatibility</td><td>OK</td><td>N/A</td><td>OK</td><td>N/A</td><td>N/A</td><td>OK</td><td>N/A</td><td>N/A</td></tr><tr><td>Authentication via request signing</td><td>Untrusted third-party requests</td><td>OK</td><td>OK</td><td>N/A</td><td>N/A</td><td>OK</td><td>N/A</td><td>N/A</td><td>?</td></tr><tr><td>Ephermal compute resources</td><td>Lightweight servers</td><td>OK</td><td>OK</td><td>OK</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>?</td></tr><tr><td>Persistent compute resources</td><td>Stopped servers</td><td>OK</td><td>N/A</td><td>N/A</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td></tr><tr><td>Ephermal storage resources</td><td>Temporary Storage</td><td>OK</td><td>OK</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td></tr><tr><td>Persistent storage resources</td><td>Permanent Storage</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td></tr><tr><td>Multiple storage resources</td><td>Complex architectures</td><td>OK</td><td>OK</td><td>OK</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>OK</td></tr><tr><td>Multiple network resources</td><td>Complex architectures</td><td>OK</td><td>N/A</td><td>OK</td><td>N/A</td><td>N/A</td><td>OK</td><td>N/A</td><td>OK</td></tr><tr><td>Static IPs</td><td>Internet-facing applications</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td></tr><tr><td>Firewalling</td><td>Basic network security</td><td>?</td><td>OK</td><td>N/A</td><td>OK</td><td>OK</td><td>N/A</td><td>N/A</td><td>OK</td></tr><tr><td>Load Balancing</td><td>Horizontal scalability</td><td>?</td><td>N/A</td><td>N/A</td><td>N/A</td><td>OK</td><td>N/A</td><td>OK</td><td>N/A</td></tr><tr><td>Billing</td><td>Business</td><td>?</td><td>N/A</td><td>OK</td><td>OK</td><td>N/A</td><td>N/A</td><td>N/A</td><td>?</td></tr><tr><td>Resource categories</td><td>Organization of resources</td><td>OK</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>?</td></tr><tr><td>Resource search</td><td>Finding Resources</td><td>OK</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>?</td></tr><tr><td>Resource tagging</td><td>Organization of resources</td><td>OK</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>OK</td><td>N/A</td><td>?</td></tr><tr><td>Collections (pass-by-reference)</td><td>Enumeration</td><td>OK</td><td>N/A</td><td>OK</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>?</td></tr><tr><td>Collections (pass-by-value)</td><td>Serialisation</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td><td>OK</td><td>?</td></tr></tbody></table></div></div><br class="table-break"/><p>For more details review the API of the different providers.
  <span class="citerefentry"><span class="refentrytitle">EC2</span></span><span class="citerefentry"><span class="refentrytitle">EH</span></span><span class="citerefentry"><span class="refentrytitle">FS</span></span><span class="citerefentry"><span class="refentrytitle">GG</span></span><span class="citerefentry"><span class="refentrytitle">SC</span></span><span class="citerefentry"><span class="refentrytitle">CS</span></span><span class="citerefentry"><span class="refentrytitle">VM</span></span></p></div><div class="section" title="Conclusions"><div class="titlepage"><div><div><h2 class="title"><a id="id36063578"/>Conclusions</h2></div></div></div><p>The previous sections described to what extent Cloud requirements
    for an API exist. What’s missing up to now is a general solution that fits
    most of the needs, is simple to implement, highly responsive (throughput),
    globally applicable (standard well known as well as dynamic connections),
    secure, highly recognized (commonly known and implemented) and last but
    not least standardized.</p><p>This working group plans to use these Use Cases and requirements for
    the creation of an Cloud API.</p><p>Similar work has been done in the Cloud Computing Use Case group.
    This document is published as the 'Cloud Computing Use Cases Whitepaper'.
    <span class="citerefentry"><span class="refentrytitle">CCUCW</span></span></p></div><div class="section" title="Contributors"><div class="titlepage"><div><div><h2 class="title"><a id="id36063609"/>Contributors</h2></div></div></div><p>The following people have contributed to the requirements gathering
    and Use Case documentation.</p><div class="table"><a id="id36063618"/><p class="title"><b>Table 13. List of contributors</b></p><div class="table-contents"><table summary="List of contributors" border="1"><colgroup><col/><col/></colgroup><thead><tr><th style="text-align: center">Name</th><th style="text-align: center">Affiliation</th></tr></thead><tbody><tr><td>Michael Behrens</td><td>R2AD</td></tr><tr><td>Richard Davies</td><td>ElasticHosts</td></tr><tr><td>Andy Edmonds</td><td>Intel - SLA@SOI project</td></tr><tr><td>Sam Johnston</td><td>Australian Online Solutions</td></tr><tr><td>Ignacio M. Llorente</td><td>DSA-Research at UCM - RESERVOIR project</td></tr><tr><td>Thijs Metsch (Editor)</td><td>Sun Microsystems - RESERVOIR project</td></tr><tr><td>Gary Mazzaferro</td><td>OCCI Counselour - Exxia, Inc.</td></tr><tr><td>George Reese</td><td>O'Reilly</td></tr><tr><td>Luis Rodero-Merino</td><td>Telefónica I+D</td></tr><tr><td>Shlomo Swidler</td><td>MyDrifts</td></tr><tr><td>Tino Vázquez</td><td>DSA-Research at UCM - RESERVOIR project</td></tr></tbody></table></div></div><br class="table-break"/></div><div class="section" title="Intellectual Property Statement"><div class="titlepage"><div><div><h2 class="title"><a id="id36063761"/>Intellectual Property Statement</h2></div></div></div><p>The OGF takes no position regarding the validity or scope of any
    intellectual property or other rights that might be claimed to pertain to
    the implementation or use of the technology described in this document or
    the extent to which any license under such rights might or might not be
    available; neither does it represent that it has made any effort to
    identify any such rights. Copies of claims of rights made available for
    publication and any assurances of licenses to be made available, or the
    result of an attempt made to obtain a general license or permission for
    the use of such proprietary rights by implementers or users of this
    specification can be obtained from the OGF Secretariat.</p><p>The OGF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary rights
    which may cover technology that may be required to practice this
    recommendation. Please address the information to the OGF Executive
    Director.</p></div><div class="section" title="Disclaimer"><div class="titlepage"><div><div><h2 class="title"><a id="id36063783"/>Disclaimer</h2></div></div></div><p>This document and the information contained herein is provided on an
    “As Is” basis and the OGF disclaims all warranties, express or implied,
    including but not limited to any warranty that the use of the information
    herein will not infringe any rights or any implied warranties of
    merchantability or fitness for a particular purpose.</p></div><div class="section" title="Full Copyright Notice"><div class="titlepage"><div><div><h2 class="title"><a id="id36063799"/>Full Copyright Notice</h2></div></div></div><p>Copyright (C) Open Grid Forum (2009). All Rights Reserved.</p><p>This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it or
    assist in its implementation may be prepared, copied, published and
    distributed, in whole or in part, without restriction of any kind,
    provided that the above copyright notice and this paragraph are included
    on all such copies and derivative works. However, this document itself may
    not be modified in any way, such as by removing the copyright notice or
    references to the OGF or other organizations, except as needed for the
    purpose of developing Grid Recommendations in which case the procedures
    for copyrights defined in the OGF Document process must be followed, or as
    required to translate it into languages other than English.</p><p>The limited permissions granted above are perpetual and will not be
    revoked by the OGF or its successors or assignees.</p></div><div class="section" title="References"><div class="titlepage"><div><div><h2 class="title"><a id="id36063818"/>References</h2></div></div></div><div class="bibliolist"><div class="biblioentry"><a id="id36063825"/><p>[<abbr class="abbrev">CCUCW</abbr>] <span class="author">. </span><span class="address">http://www.scribd.com/doc/17929394/Cloud-Computing-Use-Cases-Whitepaper. </span><span>Cloud Computing Use Cases Whitepaper</span></p></div><div class="biblioentry"><a id="id36063845"/><p>[<abbr class="abbrev">CS</abbr>] <span class="address">http://www.rackspacecloud.com/cloud_hosting_products/servers/api. </span><span>Cloud Servers API</span></p></div><div class="biblioentry"><a id="id36063859"/><p>[<abbr class="abbrev">EC2</abbr>] <span class="address">http://aws.amazon.com/ec2/. </span><span>Amazon Elastic Compute Cloud</span></p></div><div class="biblioentry"><a id="id36063873"/><p>[<abbr class="abbrev">EH</abbr>] <span class="address">http://www.elastichosts.com/products/api. </span><span>ElasticHosts API</span></p></div><div class="biblioentry"><a id="id36063886"/><p>[<abbr class="abbrev">FS</abbr>] <span class="address">https://api.flexiscale.com/current/doc/. </span><span>Flexiscale API</span></p></div><div class="biblioentry"><a id="id36063900"/><p>[<abbr class="abbrev">GG</abbr>] <span class="address">http://wiki.gogrid.com/wiki/index.php/API. </span><span>GoGrid API</span></p></div><div class="biblioentry"><a id="id36063913"/><p>[<abbr class="abbrev">ONE</abbr>] <span class="address">http://www.opennebula.org/. </span><span>OpenNebula website</span></p></div><div class="biblioentry"><a id="id36063926"/><p>[<abbr class="abbrev">RV</abbr>] <span class="address">http://www.reservoir-fp7.eu/. </span><span>RESERVOIR project website</span></p></div><div class="biblioentry"><a id="id36063940"/><p>[<abbr class="abbrev">SC</abbr>] <span class="address">http://kenai.com/projects/suncloudapis/pages/Home. </span><span>The Sun Cloud API</span></p></div><div class="biblioentry"><a id="id36063954"/><p>[<abbr class="abbrev">SLA_SOI</abbr>] <span class="address">http://sla-at-soi.eu/. </span><span>SLA@SOI project website</span></p></div><div class="biblioentry"><a id="id36063967"/><p>[<abbr class="abbrev">VM</abbr>] <span class="address">http://www.vmware.com/products/vsphere/. </span><span>VWware vSphere</span></p></div></div></div></div></body></html>
